• Re: Error when accepting a calendar invite on Thunderbird: Processing message failed. Status: 80004005. #17915

Summary

If a client attempts to create (PUT) a calendar object whose UID already exists in the target calendar, NC currently responds with a generic 400 Bad Request ("Calendar object with uid already exists in this calendar collection."). RFC 4791 specifies a separate precondition for this exact case. This PR implements it:

CalDavBackend::createCalendarObject now throws OCA\DAV\CalDAV\Exception\UidConflict (inherits from Sabre\DAV\Exception\Conflict -> 409), which satisfies the RFC 4791 precondition (Section 5.3.2.1) CALDAV:no-uid-conflict with a DAV:href pointing to the existing object:

<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>OCA\DAV\CalDAV\Exception\UidConflict</s:exception>
  <s:message>Calendar object with uid already exists in this calendar collection.</s:message>
  <cal:no-uid-conflict xmlns:cal="urn:ietf:params:xml:ns:caldav">
    <d:href xmlns:d="DAV:">/remote.php/dav/calendars/USER/personal/EXISTING.ics</d:href>
  </cal:no-uid-conflict>
</d:error>

This ensures the server is spec-compliant and provides the client with a machine-readable reference to the conflicting object, allowing the client to correct itself (by writing to the href or synchronizing).

Status 409 instead of 403: RFC 4791 Section 1.3 - the client CAN resolve the conflict and resend, hence 409 (not 403).

Background / Motivation

If you accept an email event invitation from NC in Thunderbird and try to add it to the calendar of the same NC instance as the organizer before Thunderbird has synchronized its calendar with NC, Thunderbird will attempt to PUT the event using a UUID that already exists on the server.
This is a client issue (Thunderbird should sync before accepting) and is known as: Thunderbird Bug 1717401 ("Accepting invitation before calendar sync fails (Status 80004005)"). This PR does not resolve this issue in NC. It merely makes the server response more precise - providing a clean basis for a client (TB) to respond to.

Testing

Manuell live (CalDAV-PUT gegen eine laufende Instanz):

• Created an event in the web interface and saved the ICS file via export. Sent a PUT request to the same calendar with this ICS file using Curl and checked the response. -> 409 Conflict with cal:no-uid-conflict + d:href

$ curl -s -w "\n--> %{http_code}\n" -u admin:admin -X PUT -H "Content-Type: text/calendar; charset=utf-8" --data-binary @event2.ics http://nextcloud-dev:8080/remote.php/dav/calendars/admin/personal/deposited.ics
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>OCA\DAV\CalDAV\Exception\UidConflict</s:exception>
  <s:message>Calendar object with uid already exists in this calendar collection.</s:message>
  <cal:no-uid-conflict xmlns:cal="urn:ietf:params:xml:ns:caldav">
    <d:href xmlns:d="DAV:">/remote.php/dav/calendars/admin/personal/8242054B-8CD2-42C9-BD92-543C5FF5BC0F.ics</d:href>
  </cal:no-uid-conflict>
</d:error>

--> 409

• Confirmed with the real Thunderbird (152): TB now receive a 409 UidConflict with no-uid-conflict/href during "accept-before-sync" instead of the generic 400 (see video)

Duplicate-UID behavior across CalDAV servers

Note

Changing the exception class affects one catch site outside the diff: CalendarImpl::createFromStringInServer (catch (Conflict)) now wraps the duplicate-UID case into the contractual CalendarException instead of letting the former BadRequest escape uncaught. No other catch sites are affected.

TODO

• Accept the new RFC interpretation (409 vs 403 instead 400)
• Review the code

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI
• Suggested code changes to me
• Wrote the unit test